Skip to content

CASSANDRA-21433: OpenTelemetry tracing initial implementation#4872

Open
yukim wants to merge 1 commit into
apache:trunkfrom
yukim:CASSANDRA-21433
Open

CASSANDRA-21433: OpenTelemetry tracing initial implementation#4872
yukim wants to merge 1 commit into
apache:trunkfrom
yukim:CASSANDRA-21433

Conversation

@yukim

@yukim yukim commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

This is the implementation of CEP-32: OpenTelemetry tracing integration.

Review points

  • The way of configuring OpenTelemetry
  • Check if span name cardinality is OK
    • Coordinator span is created for Query/Prepare/Execute/Batch native protocol messages with CQLStatement#getQuerySummary() result. For example, QUERY SELECT ks.table.
    • Replica spans are created for Local read/mutation runnables and inbound messages with verb + additional info, ex. MUTATION_REQ ks.table
  • Check if attribute names and values set are OK

@michaelsembwever michaelsembwever self-requested a review June 8, 2026 10:14
Comment thread conf/cassandra.yaml
# If enabled, Cassandra can export telemetry using OpenTelemetry.
# Currently, only tracing is exported
# Default: false
opentelemetry_enabled: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move up to start section of EXPERIMENTAL FEATURES

# If enabled, Cassandra can export telemetry using OpenTelemetry.
# Currently, only tracing is exported
# Default: false
opentelemetry_enabled: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move up to start section of EXPERIMENTAL FEATURES

if (Span.current().getSpanContext().isValid())
{
String target = cm.getPartitionUpdates().stream()
.map((pu) -> pu.metadata().toString()).collect(Collectors.joining(" "));

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

performance ? (on all usages of .stream())

@michaelsembwever

michaelsembwever commented Jun 8, 2026

Copy link
Copy Markdown
Member

question on package naming.

it doesn't look like we'll use otel for metrics or logs, just for tracing. if that's a safe presumption it would make more sense to put classes into the existing .tracing package rather than create a new top-level package .telemetry

question on statement values.

are we sure we are redacting all cql values ?

return;

state.trace(message);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so if IIUC…

we can have otel and internal-tracing off, we can have just otel, or just internal-tracing, or we have have both on. and these states don't impact the other…

while the CEP has stated replacing internal-tracing as a non-goal, i am interested in vague sketching of how we could eventually do that. the only functionality needed to carry forward is the tracing on; output in cqlsh (any notion of sampling and querying system_traces is redundant if otel is being used). then cqlsh tracing would ideally be done in-memory only (flushing system_traces is waste).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants